Revert "Link LLVM dynamically on aarch64-apple-darwin" and "re-enable enzyme/autodiff builds on dist-aarch64-apple"#154485
Conversation
b03112a to
0ae31c4
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@bors r+ p=10 rollup=never (unblock bootstrap on macos) |
This comment has been minimized.
This comment has been minimized.
…ieyouxu Revert "Link LLVM dynamically on aarch64-apple-darwin" This reverts commit e7c268f. This approach was much better than the last time, as it didn't break downstream users like miri. Unfortunately, it still broke rustc contributors and is blocking some people: #154408 The previously discussed solution (symlink) didn't seem to work for a user, and shipping two full copies of LLVM (old + new name) until the next stage0 compiler bump should probably be discussed first. We now also have artifacts of a nightly or two, which can be used for local experimenting, so hopefully next time we won't break anyone at all. cc @sgasho r? @jieyouxu
0ae31c4 to
0d3d1ac
Compare
|
This pull request was unapproved. Auto build was cancelled due to push. Cancelled workflows: |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing e161368 (parent) -> c4db0e1 (this PR) Test differencesShow 1 test diffStage 2
Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c4db0e127c6e96d1798423bf9f205fd06f5481a6 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (c4db0e1): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 13.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 484.178s -> 485.299s (0.23%) |
`rustc-llvm-proxy` used to work on musl targets by accident because
`LD_LIBRARY_PATH` let it `dlopen` our shared LLVM library.
After switching to `rpath`, that no longer works: our shared LLVM
library is not visible to `rustc-llvm-proxy`, and musl Rust toolchains
ship `libLLVM` statically, so there is no shared library for
`rustc-llvm-proxy` to load. This caused CI failures such as:
unable to read dir /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib: No such file or directory (os error 2)
thread 'test_link_ir_files' (4) panicked at /rustc/cf7da0b7277cad05b79f91b60c290aa08a17a6f0/library/core/src/panicking.rs:225:5:
[...]
unable to read dir /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib: No such file or directory (os error 2)
unable to read dir /root/.cargo/lib: No such file or directory (os error 2)
thread 'test_link_ir_files' (4) panicked at /home/runner/work/bpf-linker/bpf-linker/bpf-linker/target/x86_64-unknown-linux-musl/debug/build/aya-rustc-llvm-proxy-5f163ea45ef44b54/out/llvm_gen.rs:14919:10:
LLVMParseIRInContext2: DlSym { source: "Symbol not found: LLVMParseIRInContext2" }
The behavior on darwin targets is not reliable. Stable Rust toolchains
for macOS link `libLLVM` statically. Nightly tried to switch to dynamic
linking[0][1], but those attempts were reverted twice[2][3].
Prevent any related issues by excluding `default` and `rust-llvm-*`
features on darwin and musl targets.
[0] rust-lang/rust#152768
[1] rust-lang/rust#151063
[2] rust-lang/rust#153079
[3] rust-lang/rust#154485
`rustc-llvm-proxy` used to work on musl targets by accident because
`LD_LIBRARY_PATH` let it `dlopen` our shared LLVM library.
After switching to `rpath`, that no longer works: our shared LLVM
library is not visible to `rustc-llvm-proxy`, and musl Rust toolchains
ship `libLLVM` statically, so there is no shared library for
`rustc-llvm-proxy` to load. This caused CI failures such as:
unable to read dir /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib: No such file or directory (os error 2)
thread 'test_link_ir_files' (4) panicked at /rustc/cf7da0b7277cad05b79f91b60c290aa08a17a6f0/library/core/src/panicking.rs:225:5:
[...]
unable to read dir /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib: No such file or directory (os error 2)
unable to read dir /root/.cargo/lib: No such file or directory (os error 2)
thread 'test_link_ir_files' (4) panicked at /home/runner/work/bpf-linker/bpf-linker/bpf-linker/target/x86_64-unknown-linux-musl/debug/build/aya-rustc-llvm-proxy-5f163ea45ef44b54/out/llvm_gen.rs:14919:10:
LLVMParseIRInContext2: DlSym { source: "Symbol not found: LLVMParseIRInContext2" }
The behavior on darwin targets is not reliable. Stable Rust toolchains
for macOS link `libLLVM` statically. Nightly tried to switch to dynamic
linking[0][1], but those attempts were reverted twice[2][3].
Prevent any related issues by excluding `default` and `rust-llvm-*`
features on darwin and musl targets.
[0] rust-lang/rust#152768
[1] rust-lang/rust#151063
[2] rust-lang/rust#153079
[3] rust-lang/rust#154485
This reverts commit e7c268f.
This approach was much better than the last time, as it didn't break downstream users like miri.
Unfortunately, it still broke rustc contributors and is blocking some people: #154408
The previously discussed solution (symlink) didn't seem to work for a user, and shipping two full copies of LLVM (old + new name) until the next stage0 compiler bump should probably be discussed first. We now also have artifacts of a nightly or two, which can be used for local experimenting, so hopefully next time we won't break anyone at all.
cc @sgasho
r? @jieyouxu